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BUILD AND OPERATE PROGRAM PROCESS FRAMEWORK 



AND EXECUTION 



Field of the Invention 



This invention relates to build and operate programs, and particularly, to a process 



framework for such programs and their execution. 

Background of the Invention 

A program is marked by its size and complexity. It may conveniently be understood 
10 as a group of related projects which are managed in a coordinated way to achieve a long-term 
build and operate objective. 

To illustrate this important aspect, it is useful to consider what is commonly known 
as "the Space Program". One such current program is that to build and operate the 

15 International Space Station in Earth orbit. The program is of enormous complexity, and 
includes, for example, building and delivering component modules of the space station, 
delivering the modules to the site in space, assembling the modules, and training astronauts in 
the operation and maintenance of the finally assembled space station. The build and operate 
program aspects are distributed over many geographical sites in different countries of the 

20 world, and in space. 

Another example of a program, from the commercial arena, is the creation of a 
global e-business providing an entirely new service, or a large corporation moving to a new 
business model to deliver its existing products and services to the global market using the 
25 internet and e-commerce. 

A further example of a program is providing technology for a large-scale sporting 
event, such as the Olympic Games. The program involves building and operating the 
Olympic Games technology across multiple venues, each staging multiple events over 
30 multiple days. Component projects can, for example, relate to building and operating 
information technology infrastructure, computer application systems, and 
telecommunications systems, the training and deploying of staff, and defining the processes 
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for the collection and dissemination of results information to the media for the duration of the 
sporting events. 

A characteristic shared by many technology programs is the need to "fast track" the 
5 build and operate phases in order to collapse time. Fast-tracking involves the overlapping of 
design and development activities, and the deployment and operation of some program 
components while others are still in the build phase. Fast-tracking increases the complexity 
of a program and increases the risk of cost and schedule overruns. 

10 A build and operate technology program incorporates a number of management 

disciplines, each with their own specialist methodologies or process frameworks. Three of 
the key disciplines are project management, technology management and process 
management, for each of which a number of mature and widely accepted methodologies are 
known. However, individually, these methodologies either do not adequately address the 

15 complexity encountered in large-scale technology programs, or they do not deal with both the 
build and operate phases. Mature and accepted methodologies for large technology programs 
do not exist, and the integration of discipline-based methodologies is difficult because of 
conflicts in the application of core management principles or terminology. 

20 An example of project management methodology is the Project Management Body 

of Knowledge (PMBoK) published by the Project Management Institute of Four Campus 
Boulevard, Newtown Square, Pennsylvania 19073-3299, a worldwide certification body that 
certifies practitioners in project management competency. 

25 Another example of prior art in technology management are the System 

Development Life Cycle (SDLC) Methodologies, produced by international IT consultancies, 
such as Information Engineering, Method 1, Navigator and WSDDM, that focus on the build 
phase of Information Technology projects. 

30 An example of a process methodology is the Capability Maturity Model (CMM) 

from the Software Engineering Institute (SEI) at Carnegie Mellon University in Pittsburg, 
USA. SEI acts as a worldwide certification body in the software engineering competency. 
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The focus of CMM is the build phase of software engineering projects. 

Large build and operate technology programs that are undertaken without an 
adequate methodology or process framework are susceptible to failure for a number of 
5 reasons, the more common of which are: 

• Cost and schedule overruns because of an inability to define the scope of work and 
contractual obligations of each sub-contractor or project team in a way which supports a 
fast-track approach and changing organization structures during the transition from build 

10 to operate phases. 

• Cost and schedule overruns because of inadequate Cost/Schedule Control Systems (CS 2 ) 
and related processes such as deliverables management and change management. 

• Conflicts between the discipline-based methodologies of sub-contractors, when the 
program management methodology does not provide adequate integrating mechanisms. 

15 • An inability to perform total risk management (risk assessment, apportionment . to 
sub-contractors, risk mitigation and contingency management). 

• Missing deployment schedule dates because of difficulties coordinating the delivery and 
integration of components from sub-contractors. 

• Missing deployment schedule dates because operational process development, staffing 
20 and logistics support schedules are not integrated with technology build activities. 

• Disputes relating to the quality of deliverables by sub-contractors, particularly in relation 
to services, because of inadequate methods for defining, negotiating and reporting on 
service levels. 

• Difficulty in managing the huge number of tasks/activities. 

25 • Failure to recognise the changes in skill required from building to operating. 

It is the object of the present invention to avoid or at least reduce the disadvantages 
in prior art and to provide a framework suited to build and operate programs. 

30 Summary of the Invention 

The invention discloses a framework for a build and operate program, comprising: 
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one or more build processes; 

one or more operate processes; 

one or more management processes; and 

a plurality of links formed as outputs from said build, operate and management 
5 processes that form inputs to one or more other build, operate or management processes; 

and wherein a said link has associated with it exit conditions that must be satisfied 
before the link can be traversed from output to input. 

The invention further provides a framework for a large-scale sporting event, 
10 comprising: 

a set of build processes generally followed by a set of testing processes, generally 
followed by a set of operations processes, generally followed by a set of game-day processes; 

a set of management processes related to all of said build, testing, operations, and 
game-day sets of processes; 
15 a plurality of links formed as outputs from individual build, test, operate, game-day, 

and management processes that form inputs to one or more other build, test, operate, 
game-day, and management processes; and 

wherein said link has associated with it exit conditions that must be satisfied before 
the link can be traversed from output to input. 

20 

The invention furhter provides a method for establishing a build and operate 
program, comprising the steps of: 

defining one or more build processes; 

defining one or more operate processes; 
25 defining one or more management processes; 

forming a plurality of links as outputs from said build, operate, and management 
processes and inputs to one or more other build, operate, or management processes. 

The invention further discloses a method for executing a build and operate program, 
30 comprising the steps of: 

defining one or more build processes; 
defining one or more operate processes; 
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defining one or more management processes; 

forming a plurality of links as outputs from said build, operate, and management 
processes and inputs to one or more other build, operate, or management processes; and 

allowing a link to be traversed from output to input in the course of executing the 
5 program only if exit conditions associated with it are satisfied. 

The build processes can precede the operate processes, with an overlapping 
boundary therebetween such that some operate processes are able to be executed before all 
build processes are executed. Sequentially linked build and operate processes are assigned to 
10 one of a plurality of prescribed process streams, and links spanning across two or more 
process streams form planning milestones so far as the outputs represented by the link are 
concerned. In one form, each management process is linked only to either a build process or 
an operate process. The exit conditions can represent deliverable products or services that 
have been agreed to be provided. 

15 

The exit conditions can be determined by the steps of: beginning with an ultimate 
operate process, determining what requirements should be met to perform that process 
defining exit criteria for immediately preceding processes and continuing to progressively 
determine requirements for preceding processes to determine exit criteria for each said 
20 process. 

The invention yet further provides a method for executing a large-scale sporting 
event, comprising the steps of: 

defining a set of build processes generally followed by a set of testing processes, 
25 generally followed by a set of operations processes, generally followed by a set of game-day 
processes; 

defining a set of management processes related to all of said build, testing, 
operations, and game-day processes; 

forming a plurality of links as outputs from individual build, test, operate, game-day, 
30 and management processes; and 

allowing a link to be traversed from output to input in the course of executing the 
program only if exit conditions associated with it are satisfied. 
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The invention yet further provides a method for executing a build and operate 
program, comprising the steps of: 

determining program requirements; 
5 defining build, operate, and management processes, and related links therebetween, 

based on said requirements, said links between processes only being traversable if exit 
conditions associated with each are satisfied; and 

traversing said processes over time. 

10 The invention yet furhter provides a method for executing a build and operate 

program comprising the steps of: 

determining program requirements; 

defining build, operate, and management processes, and related links therebetween, 
based on said requirements; 

15 beginning with an ultimate operate process, considering what requirements 

should be met to perform that process defining exit criteria for immediately preceding 
processes and continuing to progressively determine requirements for preceding processes to 
determine exit criteria for each said process, said exit criteria required to be satisfied before a 
link between processes can be traversed; and 

20 traversing said processes over time. 

The invention yet further provides a method for executing a build and operate 
program, comprising the steps of: 

beginning with an ultimate operate process, determining what requirement should be 
25 met to perform that process, defining exit criteria for immediately preceding processes, and 
continuing to progressively determine requirements for preceding processes to determine exit 
conditions for each said process, said exit criteria required to be satisfied before a link 
between processes can be traversed. 

30 Brief Description of the Drawings 

A number of embodiments of the invention will now be described with reference to 
the accompanying drawings, in which: 
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Fig. 1 is a schematic block diagram of a generalised build and operate program 
framework in accordance with the invention; 

Fig. 2 is a schematic block diagram of the 'minimum set' program framework; 
5 Fig. 3 is a schematic block diagram showing detail of staged interaction between 

build and operate phases; 

Fig. 4 is a schematic block diagram showing link inputs and outputs in more detail; 

Figs. 5A and 5B shows two flow diagrams relating to program framework definition 
and execution; 

10 Fig. 6 is a schematic block diagram embodying the invention relating to an Olympic 

Games program; 

Fig. 7 is a schematic block diagram showing sub-processes of the processes in 

Fig. 5; 

Fig. 8 is a schematic block diagram showing underlying activities of an Olympic 
1 5 Games program; 

Fig. 9 is a diagram showing a generalised build process and associated outputs and 
exit conditions; 

Fig. 10 is a schematic block diagram showing staged transition from build to operate 
process phases; 

20 Fig. 11 is a schematic block diagram showing the OPM methodology in a 

generalised manner; 

Figs. 12A-12D show a Process Level Definition (PLD) diagram for the sport of 
Badminton; 

Figs. 13 and 14 show an Activity Level Definition (ALD) diagram for two 
25 Badminton processes; 

Fig. 15, 16A and 16B shows an Interprocess Level Definition (ILD) diagram for 
interprocess dependencies relating to Badminton; 

Fig. 17 shows a global risk mitigation ALD for the Manual Report scenario; 

Fig. 18 shows a global risk mitigation ALD for the Swiss Timing Interface Feed fails 
30 scenario; 

Fig. 19 shows a process framework produced by the OR 100 methodology; and 
Fig. 20 shows a process block diagram for the SIPOC methodology. 
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Detailed Description Including Best Mode 

Program Framework 

5 Fig. 1 shows a generalized build and operate program framework 10 that can be 

applied to a program having any purpose. The framework 10 includes a plurality of build 
processes, Bi, B2, B3, B x , 20-26. Further, there are a plurality of operate processes, Oj, 0 2 , 
O3, O y , 30-36. Finally, there are a plurality of management processes, Mi, M 2 , ... M 25 
40-44. The framework 10 thus is required to have the three basic types of processes: build, 
1 0 operate, and management. 

Each of the individual build, operate, and management processes can have 
relationships with one or more other processes of the same type, or of the other two types. 
These relationships are referred to as "links". A link forms the output from one process and 
15 the input to one or more other processes. It is thus a 1-to-n mapping between output and 
inputs. Links are "traversed" from output to input. 

In Fig. 1, the multiple links, L a , are indicated by the broad line 50. The multiple 
links, L b between the operate processes 30-36 are indicated by the broad line 60. The 

20 multiple links, L c , between the management processes 40-44 are indicated by the broad line 
70. As noted above, links also are formed between processes of different types, and the links, 
L d , between the build processes 20-26 and the operate processes 30-36 are indicated by the 
broad line 80. In a similar way, the links L e , between the build processes 20-26 and the 
management processes 40-44 are indicated by the broad line 90. Finally, the links, L f , 

25 between the operate processes 30-36 and the management process 40-44 are indicated by the 
broad line 100. 

Whilst all of the multiple links within processes of the same type and between 
processes of the different type 50, 60, 70, 80, 90, 100 are indicated as being bi-directional (for 
30 the sake of illustration), it is to be appreciated that a link is only uni-directional, having a 
single output from a process and having an input to another process. Where the output from 
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one process serves as an input to (for example) two processes, then it is to be thought of as 
constituting two links. 

In addition to links formed between the basic classes of build, operate and 
5 management processes, there also can be 'external' links (ie. to external stakeholders) 
formed. Fig. 1 also shows such links 28, 38, 48 providing inputs and outputs, to the build 
processes, B x , operate processes, O x , and management processes, M x , respectively. 

The framework 10 shown in Fig. 1 is generalized, and must be specifically 
1 0 configured in consideration of the specific program at hand. This will be described further 
below. 

Fig. 2 shows a minimum set framework 10' where there is a single build process, 
Bi, 20' having input links 28', links, L c , 80' with a single operate process, Oi, 30'. The 
15 operate process has a single external output link 38'. A single management process, Mi, 40' 
has links, L e , 90' with the build process 20', and links, L f , 100' with the operate process 30'. 

Fig. 3 shows two build processes 20-22 having links principally with respective 
operate processes 30, 32. The first build process, Bi, 20 has four links 110-116 with the 
20 operate process, Oi, 30. Fig. 3 indicates that these links 1 10-1 16 are traversed at relatively 
different times, in what can be considered as a staged manner. In other words, the four links 
110-116 that must be traversed to move from the build process 20 to the operate process 30 
tend to occur at sequential points in time. 

25 In a similar way, the second build process, B 2 , 22 has three links 120-124 with the 

second operate process, O2, 32. These links 120-124 also are traversed in sequence so the 
transition between build and operate is made in that manner. 

Other links 140-144 have been shown relating to other aspects of the process 
30 interaction, and their relation in time, given that Fig. 3 broadly indicates the passage of time 
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in a left-to-right direction. 

Fig. 4 is a schematic block diagram showing further details of a build process, Bi, 20 
having links with two operate processes, Oi and 02, 30-32. This simplified view indicates 
5 that the link identified by the number 150 forms an output to build process 20 and an input to 
operate process 30. At the output of the build process 20 there is a logic block 160 that 
performs a test to determine whether three exit conditions 162-166 have been satisfied. The 
link 150 between the build process 20 and the operate process 30 can only be traversed if all 
three exit conditions have been satisfied. In a similar way, the link 170 from the build 
10 process 20 to the second operate process 32 can only be traversed if the logic block 180 
assesses that the two indicated conditions 166 and 182 are satisfied. 

It is convenient to think of "exit conditions" as being (i) "acceptance criteria", where 
deliverables/products are concerned, and (ii) "service level agreements", where services/tasks 
15 are concerned. This will be explained more fully below. 

Establishing and Performing a Program 

Fig. 5A is a flow diagram illustrating the basic methodology for performing a build 
20 and operate program. 

A generic program framework is established in step 200, having build, operate, and 
management processes, as described above with reference to Fig. 1 . In the following step 
(step 205), the program requirements are determined, in terms of all specified or necessary 

25 inputs and outputs. In step 210, the framework is then configured to meet the requirements 
by establishing links between processes and exit conditions that apply to each link. Once so 
configured, the framework is then traversed, in step 215, in the sense that with time process 
exit conditions are satisfied and a link may validly be traversed. Thus the program 
framework can be considered as spreading, generally, from build through to operate as links 

30 are able to be traversed. 
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Fig. 5B shows alternate broad process steps that are undertaken in establishing and 
performing a build and operate program in another embodiment. Steps in common with Fig. 
5A have like reference numerals. 

5 A generic program framework 10 is established (step 200) having build, operate, and 

management processes as described above with reference to Fig. 1 . It is then necessary, in 
step 220, to configure the program requirements, including links between the specific 
processes. Typically this is performed by bringing together a number of stakeholders to 
consider all possible inputs to, and outputs from the program, together with all specified or 
10 required deliverables or products and service (ie. outputs). 

In step 225, each process, or linked process stream, is considered from the point of 
view of its criticality to the program. Criticality takes into account in known or assessed risk 
factors and quality considerations. The step of ascribing processes to criticality classes 
15 generally means that more project time is allocated to processes that involve high degrees of 
risk or more demanding levels of quality. The consideration of risk and quality in the 
definition of program processes obviates the need to consider risk and quality as functions of 
individual tasks, as is known in the prior art. Depending upon the decided rating, the process 
is ascribed to a specific class. 

20 

In step 230, a negotiation takes place to define specific outputs from each process, 
providing inputs to a linked process or processes. Subsequently, an individual process owner 
is assigned to each process (step 235). The idea of responsibility for processes being ascribed 
to individual persons is a feature of the invention that differs from the prior art. One incident 
25 of ascribing owners to processes is that each such person then also owns the risk, and must 
plan, manage and report on that risk. This onus has the effect of decreasing the likelihood 
that critical processes will fail for want of attention. 

In step 240, the processes have a respective methodology, determined by their 
30 criticality class, applied to them to determine the exit conditions that apply (remembering that 
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the links and outputs between processes have already been defined). As it would be 
expected, those processes in the class having the greatest criticality will have, on average, the 
greatest number of exit conditions applying. 

5 Now that the framework has been fully populated (in terms of the definition of 

processes, links, outputs and exit conditions), the discrete outputs are entered into a 
scheduling tool (step 245) so that tasks can be planned in time, and then followed. Certain 
sets of links and exit conditions are grouped to form milestones which are used to assist in 
monitoring the execution of the program. This will be described in further detail presently. 

10 

The configured framework thus can now be traversed to execute the program (step 
215), with status reports against milestones providing the primary schedule control 
mechanism. 

15 The broad steps relating to performance of a build and operate program as described 

above will now be further described with reference to a specific example, namely that of 
staging an Olympic Games. 

Olympic Games Example 

20 To place the size of the program that constitutes the Olympic Games in perspective, 

it is useful to mention certain statistics concerning the Year 2000 Olympic Games held in 
Sydney, Australia. About 10,300 athletes will be competing overall. There are 28 sports 
conducted over 640 morning, afternoon and evening sessions at 30 venues. In addition to the 
athletes, there are 5,100 officials, 50,000 volunteer workers, and 12,000 accredited media. 

25 The broadcast audience is estimated at 3.5 billion. The main stadium, at which Athletics is 
conducted, has a capacity of 1 10,000 spectators. 

In terms of computing and telecommunications resources, 80 IBM MQ series servers 
and 3 IBM S/390 mainframes are deployed. Additionally, there will be 17,000 desktop and 
30 portable computing devices in use, as well as numerous other peripheral devices such as 
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printers, validators and displays. An estimated 13 million lines of program code was written 
to implement all the necessary applications. 

Fig. 6 is a high level representation of the build, operate, and management processes. 
5 This level of process definition has partial correspondence with step 210 in Fig. 5 A and step 
220 in Fig. 5B. As shown in Fig. 6, there are two basic build process stages 20, 22, called 
"Build Processes" and "Testing Processes". These processes 20, 22 are related as essentially 
sequential blocks. The links between processes have not been shown for clarity purposes. 

10 A first operations processes 30 follows the testing processes 22. There are two 

broad management processes, the first being a Program and Business Management Processes 
40, the second being a Cross-Project Technical Management Processes 42. These two 
management processes 40, 42 will have links across the build processes 20, testing processes 
22, and operations processes 30. 

15 

The particular circumstances of this Olympics program are that there is one principal 
contractor responsible for the building processes and some of the operations processes, and 
the management processes associated with those. There are a number of sub-contractors 
involved in various of the build processes. There is additionally a governmental Organising 

20 Committee ("OC") sharing some of the management processes and the operations processes. 
Such a distribution of ownership may not be adopted in future Olympic Games. The 
distribution of ownership could be arranged such that there was a single party having total 
responsibility, or many more than two principal parties having ownership. The program 
framework of the present invention can accommodate such a range of ownership because of 

25 the deterministic nature of the individual processes ownership and exit conditions that allow 
a link therebetween to be traversed, whereas prior art arrangements would be found deficient 
if such complexity in ownership were present. 

The second operations process is the Games Processes 32. These processes 32 have 
30 links with the Organising Committee Games Processes 34, and both of those operations 
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processes are influenced by the OC Management Processes 44 and the OC Technology 
Processes 46. 

It is to be understood that while the build and operate processes are shown as being 
5 generally sequential in time, there is, in fact, considerable overlap, in that some operate 
processes begin before all build processes are completed. The analogy is that the framework 
is traversed in a spreading nature, rather than a strict sequence. 

Fig. 7 shows, in the next level of detail, component processes within the generalised 
10 processes shown in Fig. 6. The first build processes 20 are constituted by Requirements 
Baseline processes 20-1 and Architecture Baseline processes 20-2, which each have links to 
the Build Solution Components processes 20-3. There are eight program and business 
management processes, and eight cross-project technical management processes, most of 
which operate across all build and processes. 

15 

The program and business management processes 40 are named in Fig. 7 and 
designated 40-1 to 40-8. Similarly for the cross-project technical management processes 42, 
designated 42-1 to 42-8. There can be lower level or management sub-processes that link 
with individual build or operate processes, although these are not shown in Fig. 7. 

20 

The build processes 22 comprise of three groups of processes. The first is the 
Workforce and Training processes 22-1. Additionally, there is the Testing processes 22-2 
and the Device Configuration and Logistics processes 22-3. 

25 The operations processes 30 comprise a plurality of Stage Sports Events processes 

30- 1„, a plurality of Operate Venues processes 30-2 n , and a plurality of Operate TCC and 
Datacentres processes 30-3 n . 

Fig. 8 is at the individual process level, showing processes and their linkages, within 
30 the build processes phase 20, testing processes phase 22, and operations processes phase 30. 
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As such, it equates broadly to step 2 10 in Fig. 5 A and specifically to step 220 in Fig. 5B. For 
clarity, links with the Program and Business Management processes 40 and the Cross-project 
Technical Management processes 42 have been omitted. Each link constitutes an output 
from a process and an input to another process. In fact, a single link may represent multiple 
outputs (which otherwise are omitted for the sake of clarity). 

A representative listing of the build, operate and management processes created for 
the Sydney Olympics is shown in the following Tables: 
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Table 2: Cross-Project Technical Management Processes 
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Assurance 
Stream 


Test Stream 


Software 
Delivery & 

Distribu-tio 
n Stream 








PI 05 Workforce 

Training 

Management 


P98 Post 
Event/Imple 
mentation 
Review 


PI 24 Delivery 

Verification 

Test 


P26 

Software 
Delivery 








PI 06 Workforce 
Training Planning 


P99 Client 
(IF) 

Acceptance 
Test 


PI 25 Event Test 
Planning & 
Preparation 


P74 

Software 
Control & 
Distribution 








PI 07 Training 
Course 


PI 15 Plan 
& Manage 
Test Events 


PI 27 Systems 
Focus Test 










PI 08 Training 
Delivery 


PI 16 Plan 
& Manage 
Rehearsals 


PI 28 Process 
Test 














PI 29 User 
Acceptance Test 
(GMS, INFO, 
WNPA etc). 











Table 3: (Partial) Build and Operate Processes 



Customer 


Run the 


Manage 


Manage 


Operate 


TCC Mgtmt & 


Operations 


Application 


Relationship 


Games 


the DCF 


Venues 


Extended 


Administration 


Manage- 


Support 


Management 


(Technology) 






TCC 




ment 




P08 Hosting/ 


P38 


In the TCC 


In the 


P23 


P44 Technology 


PI 2 Service 


P90 


Hospitality 


Communicate 


P70 Manage 


TCC P80 


Games-Tim 


Partner Interface 


Delivery & 


Application 




with all 


the DCF 


Manage & 


e Test Mgmt 


Mgmt 


Operations 


Management 




Stakeholders 




Support 
VITMs 






Mgmt 


& Support 


PI 0 Customer 


P47 Games 


In the DCF 


For each 


P75 


P49 Internal 


P45 Data 


P91 


Satisfaction & 


Operations 


P22 


Venue 


Datacentre 


Project Perf. 


Quality 


Application 
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Expectation 
Management 


Reporting 


Configurati 
on Mgmt 


P76 

Perform 
Venue 


Disaster 
Recovery 


Reviews 


Control 


User 

Processes 








Operat-io 
ns 

Continuity 
Mgmt 
























P 14 Issue & 

Action 

Management 


P50 Technology 
Command & 
Control 


P41 Device 
Asset Mgmt 


P81 

Operate 

Non-TCC 

Venues 


P77 Switch 
to DR Site 


P52 Problem 
Management 


P65 Perform 

Operations 

Support 


P92 

Application 
Operation 




P53 Critical 

Situation 

Management 


P72 Deliver 

Mainten-anc 
e 




P86 

Datacentre 
Mgmt 


P54 Logistics 
Management 


P83 Systems 
& Technology 






P66 

Games-Time 
Planning & 
Coordination 


P73 Device/ 
System 
Deployment 
& Logistics 






P55 Service 
Requests 


P84 Network 
Management 






P67 Reporting 
to IBM HQ 


P74 

Software 
Control & 
Distribution 






P57 Performance 
& Service Level 
Monitoring & 
Reporting 


P85 Provide 
Interface to 
Internet 














P64 Operations 
Change Mgmt 


P89 Data 
Management 
& DBA 














P68 Shift 
Rostering 
















P69 TCC 
Administration 
















P82 Facilities & 
Equipment Mgmt 
















P87 Backup & 
Recovery 
















roo oecunry 
Management 
















P91 Run TCC 
Applications 
















PI 00 Workforce 
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Management 
















PI 02 Workforce 
Deployment 







Table 4: (Partial) Operate Processes 



5 

Process Outputs 

Fig. 9 is an expanded view of the "Results Process Analysis & Planning" (RPAP) 
process 250 shown highlighted in Fig. 8 showing its agreed outputs and exit conditions. 



10 The input links to the RPAP process 250 are on a 'per sport' basis. That is, the 

process has, for the Olympic Games, twenty-three sets of inputs and corresponding outputs. 
Considered then on a per sport basis, the inputs are: 



(i) complete requirements documents, 

15 (ii) venue design, 

(iii) venue build plan, 

(iv) Sport Federation Rule Book, and 

(v) expert knowlege. 



20 Items (i) to (iii) are signified as being "entry criteria", which is intended to mean that 

each has complied with an agreed program template, and has been accepted by the Program 
Technical Review Panel. This is really the same thing as having satisfied exit criteria from 
the respective preceding process (ie. Venue Planning & Design 255, and Requirements 
Baseline 260). 

25 

The outputs (ie. 'deliverables') in this instance are: 



(i) process level descriptions 

(ii) activity level description, and 
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(iii) process development & test plan. 

The "exit criteria" for each output are, as it happens, the same as the "entry criteria" 
mentioned above. 

5 

Traversing the Framework (Executing the Program) 

Fig. 10 is a conceptualised representation that demonstrates the staged transition 
between build and operate phases. 

10 In Figs. 6, 7 and 8, the boundary between build and operate phases is shown as 

discrete, and implies that it occurs in a single point in time. In actuality, the boundary is 
rather that represented in Fig. 10, where there is a staged transition, in that, as noted above, 
many operate processes begin before all build processes are completed. 

15 In a temporal sense, some operate processes will commence during a time that is 

principally concerned with testing processes, and even earlier than build processes. The 
transition between build and operate concludes with the completion of all build processes, 
and for the present example, is at a point in time 100 days prior to opening of the Olympics 
(the "100 Day Operational Readiness phase"). 

20 

Referring then to the operations processes phase shown in Fig. 10, it can be seen that 
there are various "peaks" that occur during time. These correspond with scheduled Test 
Events, where there is a staged operations rehearsal. With each subsequent such rehearsal, a 
greater proportion of the total Olympics operations processes are practised. 

25 

Fig. 10 also shows how some program management process occur only in the build 
or the operate phase, whereas others occur in both. The three processes (P37, P06 and P27) 
listed on the left-hand side occur only in the build phase. The three process (P64, P58 and 
P58) listed on the right-hand side occur only in the operate phase. The four (management) 
30 processes (P28, P21, P60, P22) shown along the bottom occur in both phases. However, 
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because of the gradual transition from build to operate, all may be operating at the same 
points in time. This arrangement is designed to clarify to build and operate teams the correct 
process to use for problem and change management depending whether the component is in 
the build or operate environment (ie. P37 is broadly equivalent to P64, P06 to P58, and P27 
5 to P52). 

Process Assurance Classes 

As described with reference to step 215 of Fig. 5, once the links and outputs between 
individual processes have been established, it is necessary to determine the assurance level of 
10 individual processes and describe each to an appropriate class. In the present example, four 
classes are utilized, as follows (in order of most critical to least critical): 





Assurance Class 


Methodology 




A 


OPM 




B 


OR100 




C 


SIPOC 




D 


Manual 



15 TableS 

The allocation of assurance class is performed objectively, and takes into account 
program deliverables in terms of products and services and an assessment of risk and quality 
assurance at a macro level. This assessment will necessarily include a consideration of 
20 contract obligations as a starting point. 

Category A processes are those that are mission critical, where failure would have a 
major impact. Such processes require formal Failure Mode Critical Analysis and risk 
mitigation. 

25 

Category B processes are those that require a formal service level agreement. 
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Category C processes are those involving multiple teams and where entry and exit 
criteria, and scheduling milestones, need to be explicitly defined. 

Category D processes are those involving a single team which has the experience to 
5 manage the risk associated with the process. 

A. OPM 

The acronym OPM stands for Olympic Process Methodology. The methodology is 
known per se. This name is chosen for convenience, and it is to be understood that the 
10 methodology is not restricted only to use in the context of an Olympic Games. 

For the purpose of illustration, the example given refers to the Results Process 
Analysis & Planning process 250 shown in Fig. 8. This process has as its outputs the 
documents shown in Fig. 9, for convenience known collectively as Process Analysis 
15 Documents (PADs) - one for each sport. PADs are developed taking into account Failure 
Mode Criticality Analysis then risk mitigation, and in this way seek to maximise the ability to 
detect problems and minimise the negative impact and cost by recognizing problems before 
they occur. 

20 For the purpose of explanation, the sport of Badminton will now be considered. 

Referring then to Fig. 11, the knowledge and information previously gathered (see 
also Fig. 9), in step 300, is input to a process level definition process, in step 302. 

25 Fig. 12A shows the basic sequence of events for Badminton. The phases are 

pre-competition 320, competition 322-326, and end-of-competition 328. Figs. 12B-12E 
show this sequence in greater detail, in the form of Process Level Definitions (PLDs), with 
the process steps 340-374 being self-explanatory. During this step the knowledge and 
information obtained/gathered in step 300 is critically analysed to determine general areas of 

30 risk. In addition typical sport exception scenarios would be created which have been known 
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to cause system failures in the past. Notes are made of these risk areas and potential risk 
mitigation strategies. At this point, target acceptable risk levels are agreed, based upon 
process criticality. This is described below as the assignment of Risk Factors (RFs). 

5 In step 304, the Activity Level Definition process occurs. The initial definition 

similarly takes into account the risk areas, critical analysis and potential risk mitigation 
strategies identified in step 302. The completed ALD is then subjected to a formal criticality 
analysis (step 306) followed by risk mitigation (step 308). Fig. 13 shows the Badminton 
ALD for the "Event Configuration" process 340. 

10 

For the purposes of the PAD (which includes the PLD and related ALD), the 
following identification scheme has been adopted, which is used in the ALD specifically to 
show dependencies. 



15 



Name of ALD 


PAD## 


Description of ALD 


Event Configuration 


aa-ECF 


Check Event Configuration and OEQ transfer 


After Entries Deadline 


ab-AED 


Check OEQ download data, verifies and updates 


Late Change request 


ba-LCR 


Requests late change, verifies and approve results 


Before the Draw 


ca-BTD 


Print for Control reports Entry List and distributes 
Pre-Draw Reports 


During the Draw 


da-DTD 


Conduct Draw and assist with Draw 


After the Draw 


ea-ATD 


Receive Draw List, Print for Control Draw Results 


Draw Press Conference 


fa-DPC 


Preparation for Competition Reports 


Midday before Competition 


ga-MBC 


Preparation for Court Assignments 


Start of Day 


ha-SOD 


Start Badmington Application ready for Event 


Start of Session 


ia-SOS 


Preparations for Official Assignments 


Before the Match 


ja-BTM 


Entering finished starting line up 


Start of Game 


ka-SOG 


Record start of game 
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Duration of Game 


la-DTG 


Initiate play by play 


End of Match 


ma-EOM 


Verification of scoresheet and checking 


End of Session 


na-EOS 


Generate match report to preparation for playing 
assignments and schedules 


End of Day 


oa-EOD 


Discusses End of Day day by day activities and 
results 


Medal Presentation 


pa-MDP 


Print for Control for Medal Presentation 



Table 6 



5 Referring to the first sub-process 380, the symbol used is in two halves. The upper 

half indicates the sub-process owner, in this case the Results Manager. The lower half 
represents a unique task number ("aa-ECF-01") and a written description: "Ensure results 
system is operational". The output of the sub-process is expressed as four variables: trigger, 
timeframe, frequency, and mode. In this example, the trigger (ie. for the next sub-process) is 
10 'results system operational', the timeframe is 5 minutes (ie. hh:mm:ss format), the frequency 
is one time ("lx"), and the mode is 'manual'. 

Referring to sub-process no. 382, it can be seen that the sequence includes decision 
elements. Here, it is asked "Is configuration correct?", and a branching occurs depending 
15 upon the answer 'yes' or 'no'. 

Fig. 14 shows a further example, in this case the Badminton ALD for the "Start of 
Day" process 356. Referring to sub-process no. 382, it can be noted that the decision element 
that has three inputs. This exemplifies that multiple inputs can exist. 

20 

The ALD can also indicate deliverables (not shown in these examples), such as 
printed reports or data feeds to other related processes, such as television broadcasting. 

Referring now to Fig. 1 1 again, in step 310, Interprocess Level definitions (ILDs) are 
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prepared. Their purpose is to define interprocess dependencies, and are useful as a 
management tool, but also in assessing criticality of the interfaces between processes. 

For the sport of Badminton there are forty-six different process owners. With such a 
5 large number of actors it becomes difficult to appreciate criticality in a meaningful way 
without some formal mechanism. This information is provided by the DLDs. Fig. 15 shows a 
portion of the ILD for Badminton, representing the relevant process responsibilities of the 
"Internet Results Team", the "INFO Application Team", the "Gateway Operators", the 
"International Federation", the "International Broadcast Centre", and the "Main Press 
10 Centre". The potential risk can be easily assessed (in part) by the number of sub-processes 
owned by each actor. In this case, the critical service levels for the process are determined by 
the International Federation. When this process is critically analysed, of the forty-six actors, 



the one with the most critical sub-processes is the Event Manager (EM), which is shown in 
Figs. 16Aand 16B. 



Once the ALDs are identified, a further failure mode criticality analysis review (step 
306) is conducted to determine which of the activities have the higher risk of failure. Clearly 
this involves the analysis of the ILDs, as just described. One component of such a review is 
to determine Risk Factors and assess whether they meet the agreed RF level. 



Risk mitigation strategies (step 308) are then devised to mitigate these risks (i.e. to 
reduce individual activity (and process) RFs), and the ALDs (and PLDs) are modified 
accordingly. 



15 



20 



25 



The risk mitigation analysis includes three steps: 



30 



2. 



3. 



1. 



Explore options to mitigate risk 

Implement changes to process, activity or inter process dependencies 

Reassess that the final risk of the process, activity or inter process dependencies is 

below the agreed "RF" level (normally RF2 or RF3) 
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In relation to the assignment of Risk Factors, a ten level scale is adopted: 



RF# 


Assessment given to each level of risk 


RF1 


multiple alternate paths extremely low risk 


RF2 


alternate paths available, very low risk 


RF3 


failure is possible, some risk 


RF4 


failure is very possible, moderate risk 


RF5 


failure is very possible & likely 


RF6 


failure is probable, risk is moderately high 


RF7 


failure is probable & likely, risk is high 


RF8 


failure is very probable & likely, risk is very high 


RF9 


failure is almost definite, risk is extreme 


RF10 


definite failure, unacceptable results 



5 



Table 7 

These risk factors assist in determination of the critical activities within the process. 

10 The criteria for the assignment of RFs 5 in this example, are: 

• Are processes fully defined, including dependencies? 

• Are there any existing alternative paths? 

• What is the risk of failure? 

• In the event of failure, how quickly does recovery occur? * 

15 

For each of RF1-RF10, the criteria are: 
RF1 

• fully defined processes, mostly defined dependencies 
20 • no existing multiple alternate paths result in failure 

• existing problems within the activity, process, interprocesses have been resolved 

JP92000017IUS1 



successfully 



-28- 



RF2 

• fully defined processes, some undefined dependencies, but no unknowns 

• no existing alternate paths result in failure 

• very low risk of failure is seen within the activity, process, or inter process 

• if failure of the activity, process or inter process occurs, recovery is immediate and 
successful 

RF3 

• fully defined processes, undefined dependencies, some unknowns 

• an alternate path can lead to failure (but highly unlikely) 

• low risk of failure is seen within the activity, process, or inter process 

• if failure of the activity, process, or inter process occurs, recovery is almost immediate, 
and mostly successful 

RF4 

• partially defined processes, undefined dependencies, many unknowns 

• alternate paths can lead to failure (and likely to occur) 

• moderate high risk of failure is seen within the activity, process, or inter process 

• if failure of the activity, process, or inter process occurs, recovery is not immediate, and is 
moderately successful 

RF5 

• some undefined processes, undefined dependencies, many unknowns 

• no alternate paths or alternate paths that lead to failure 

• risk of failure is seen to be as likely within the activity, process or inter process as success 

• if failure of the activity, process, or inter process occurs, recovery is not immediate, and is 
not always successful. 
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RF6 

• a moderate number of undefined processes, undefined dependencies, many unknowns 

• single dependencies that can fail 

• risk is seen to be more likely to fail within the activity, process, or inter process than 
5 success 

• if failure of the activity, process, or inter process occurs, recovery is not immediate, and is 
not successful 

RF7 

10 • a high number of undefined processes, undefined dependencies, many unknowns 

• single dependencies that can fail, and are likely to fail 

• failure is much more likely to occur than success 

• if failure of the activity, process, or inter process occurs, no recovery or recovery is not 
immediate, and is not successful 

15 

RF8 

• much of the process is undefined, with many unknowns 

• definite single dependencies that will fail due to large numbers of unknowns 

• failure is the probable path for the process 

20 • when failure of the activity, process, or inter process occurs no recovery is available 

RF9 

• most of the process is undefined, with many unknowns 

• multiple single dependencies that will fail due to large numbers of unknowns 
25 • failure is the most likely path for the process 

• when failure of the activity, process, or inter process occurs, no recovery is available 

RF10 

• the process is undefined, with many unknowns 
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• undefined multiple single dependencies that will fail due to large numbers of unknowns 

• failure is the only path for the process 

In exploring alternate paths, various ways of reducing the risk for each critical 
5 activity are considered. Changes are then implemented in order to achieve the reduction in 
risk. Finally, any change is assessed to determine whether it can successfully fit within the 
existing PLD or ALD. This mitigation thus can be seen as operating iteratively until a 
satisfactory RF# is achieved for each individual process, activity, or inter process 
dependencies. That is, for any activity, process or inter process dependencies, if a mitigation 
10 is worked, have the criteria, and thus the RF# reduced? If so, is the new RF# acceptable? If 
not, then perform another mitigation. 

Figs. 17 and 18 show alternate paths developed to mitigate an identified RF level 
that is too high. The mitigation strategies can be to devise one or more alternative paths, to 
15 reach a position of no unknown or undefined dependencies, or reduce recovery time. 

For a process that has as an output the production of a report (e.g. process 384 in 
Fig. 14), a mitigation is to devise an alternative path, such as shown in Fig. 17. That is, the 
risk mitigation strategy is implemented at any time the Print Distribution Team has not 
20 received a report when such should have occurred (typically at the end of a match, end of a 
session, or end of a day). This is represented by sub-process no. 390. The sequential 
sub-processes are followed until the output of the report being delivered is satisfied. 

For a process that has as a dependency a timing feed from a third party, (not 
25 specifically shown), one such mitigation is to devise an alternative path, such as shown in 
Fig. 18. This risk mitigation is implemented at any time that the Results System Manager 
(RSM) detects that the feed from Swiss Timing has failed, represented by sub-process no. 
396. 

30 B. OR100 
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This methodology is known as Operational Readiness 100, and refers to the 
principle that all build processes need to be completed such that there is operational readiness 
100 days before commencement of the Olympic Games. 

5 The underlying idea of OR 100 is to determine what deliverables or service levels are 

required for each process to be operationally ready, and working backwards from that point to 
establish preceding processes, links and exit criteria. In other words, the program framework 
is constructed from "right-to-left". 

10 Fig. 19 represents a process framework culminating in the 'Support the INTEL™ 

Base' process 400, numbered P693. The outputs for P693 are to provide and support devices 
at the Technology Command Centre and other venues, configured for each one's specific use. 
Many of the outputs are services and for these, service level agreements would be prepared. 

15 In order to achieve that level of operational readiness, the 'inputs' to process 693 

are: 

• the provision of quality management 

• management of the inventory of devices 
20 • set up of Device Configuration Facility 

• management of staff on a day-to-day basis 

• ensure adequate supply of parts 

• perform build of devices 

• ensure replacement or fixing of failed devices 
25 • unpack and install devices at venue 

• install 'Golden Code' on devices 

• retrieve devices after Test Events or completion of Games 

• maintain platform software 

30 Having determined these 'inputs' dictates corresponding processes be defined, 
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identified in Fig. 19, by the reference numerals 402-422. 

The exit criteria for each of these processes are then determined, and are as follows: 

5 P024DCF: *QA CHECKS: Performed QA checks as documented in P3 

during build phase. *M47 PASS: Passed milestone checks. 
♦CHANGE CONTROL: Installed devices are under change 
control 

P041: *INVENTORY SYSTEM: System in place showing location and 

10 status of all IBM devices. ""COMPETENT STAFF: Staff to 

operate the system have been using the system for 6 months. 
P059: *DOCUMENTED PLAN: The plan for deployment shows 

location of all Games time devices. *DEPLOYMENT PLAN: 

Delivery of all devices required forTR 1 accomplished. 
15 P068DCF: * STAFF ROSTERS COMPLETE and stall members informed on 

their place and time of duty. * STANDBY LISTS COMPLETE, 

including telephone numbers and times of availability. 

♦TRANSPORT available for standby staff. *WORKFORCE 

DATABASE complete and available. *POLICIES in place 
20 covering working hours, sick leave, etc. * STAFF AND 

VOLUNTEERS TRAINED and passed competency test. 
P070C: *AUDIT TRAIL: Documented audit trail of devices installed 

available. *PARTS DEPLOYMENT DETAILS: Parts deployed 

according to PSS plan. 

25 P071: *DOCUMENTED BUILD PLAN: Documented build plan in 

place and available for review. *STAFF: Staff identified to match 
build plan. *DEPLOYED SERVERS: Servers in place for 
deployment of software. 
P072DCF: *Documented procedures for fix vs replacement. 

30 P073c: *VISBLE INSTALLED DEVICES: Installed devices visible at 
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TCC. *DEVICE CHECK: Devices provided up and passed 
installation check. *DEPLOYMENT PLAN: Deployment plan 
documented for install teams. 
P074: *TIVOLI CODE: Code available on Tivoli servers. 

5 *DOCUMENTED PLAN: Documented plan for software 

deployment. 

P078: *DOCUMENTED PLAN: Documented bump-out plan available 

for review. *STAFF SCHEDULE: Staff schedule to perform 
device retrieval documented. 
10 P093: *CID SERVERS: CID servers deployed. *STAFF: Competent 

staff to carry out deployment have exercised the build for 6 
months. * VOLUNTEERS: Volunteers with third year attributes. 

The process framework continues to be developed from right-to-left, in the sense 
15 that 'inputs' to each of the processes 402-422 are determined. 

The following inputs are then defined: 

P059: *Venue accreditation for transport drivers. *Adequate transport 

20 capability. *Venue access restricted. 

P068DCF: *Plans for PSS approved 
P07c: *PSS plan based on device MTBF. 

P071: *Complete BoMs from VITMs. *BOMs reviewed for QA. 

* Operating system software frozen. *Base subsystem components 
25 availabe. 

P073c: *DOT plan. * Availability of volunteers. *Volunteers not present 

when rostered. 

P074 *Definition of approved code. *Person authorised to provide code 

approval. *INFO and CIS not frozen. 
30 P078: *Volunteer attendance when required. 
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P093: *Training of volunteers. *Platform software supported by 

specialists and handed over to DCF. 

This, in turn, dictates earlier processes, shown as process 430-448. 

5 

The methodology continues until at ultimate inputs are defined, thus completing the 
framework in terms of processes, links, and exit criteria. 

C. SIPOC™ 

10 This methodology is known per se, and is termed " Suppliers, Inputs, Process, 

Outputs, Customers (SIPOC™). 

The methodology identifies discrete actors, in the form, working from right to left of 
Fig. 20, of customers 508 having specific requirements and receiving outputs 506 in response 
15 thereto. In turn, the outputs specify requirements to, and receive from the process 504. 
Furthermore the process requirements are specified to the inputs 502 which also feeds the 
process 504. Finally, suppliers 500 provide specified goods and/or services to the inputs 502. 

By adopting such a model it is possible to define inputs and outputs for individual 
20 processes. SIPOC™ thus is underpinned by the need to determine what products and/or 
services are to be delivered. 

The Daily Progress Reporting process (P155) is one example for which SIPOC™ is 
implemented. The objectives of this process is to keep its customers informed at the end of 
25 each day of the operation of technology supporting the Olympic Games (ie. operations 
phase). Following the SIPOC™ methodology, the following processes are established. 



Suppliers 


Inputs 


Process 


Outputs 


Customers 


Process Owner 
Venue Data 
Sources-various 
Process Owner via 


Input Criteria Sheet 
Venus Information 
Items that match the 
Input Criteria 


Source Author Input 
- normal operation 


Completed Daily 
Report Input Form 
(form will specify 
any metrics that have 


Captain - using 
generic Notes ID 
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Notes Administrator 


Daily Report Input 


Source Author Input 


to be submitted) 


Archive Database - 




Form 


- contingency (to be 




using generic Notes 


<« 


(Notes Stationery 


defined), will involve 




ID 




Item) 


fax, email by mobile 








Reporting Deadlines 


phone, verbal by 








Contact & 


telephone 








Distribution List 








Process Owner 


Input Criteria Sheet 


Captain's Brief - 


Completed Captain's 


Information Officer - 


Source Author 


Completed Daily 


normal operation 


Briefs, by email (for 


using generic Notes 




Report Input Form 




each Information 


ID 


Process Owner via 


Input Form - 




Area x 6) 




Notes Administrator 


Captain's version 


Captains Brief - 


note - the 


Archive Database - 


i( 


Reporting Deadlines 


contingency, to be 


Technology 


using generate Noted 


*( 


Contact & 


defined, as above 


Captain's Report will 


ID 




Distribution List 




contain a large 










number of metrics 




Information Officer - 


Lotus 123 Metrics 


Prepare Daily Report 


Updated 123 


Information Officers 


Metrics 


Spreadsheets 


Metrics 


Spreadsheets in 










database 




Information Captains 


Captain's Brief, 




Graphics derived 






containing the 




from 123 






required metrics 




Spreadsheet 




Process Owner 


Input Criteria Sheet 


Produce & Publish 


Non-confidential 


Reports Database 


Captain 


Captain's Brief 


Daily Report (load in 


Report 


-Staff Reports 


Process Owner via 


Final Daily Report 


database and mark as 


Confidential Report 


Database - 


Notes Administrator 


Form 






Management 


(« 


Reporting Deadlines 


"Private") 


Olympic Client 






Contact & 




Summary Report 


(database subject to 


Information Officer - 


Distribution List 


Print hard copy and 


(distribution to be 


regular backup by 


Metrics 




hand carry to IBM 


defined) 


operations) 




Daily Report Metrics 


Games Exec for 








& Graphics 


approval 


3 x reports approved 


(no database 










replication planned 






Appiuvai vy 1D1V1 




ttt tliic ctflOf*^ 
al Ulla slagC^ 






Games (Approval) 










Exec 




Nominated IBM 








Hard Copy Reports 


(Audience) Execs 






Direct Distribute 










Hard Copy Reports 










to nominated 










recipients 










Mark approved 










report as "Public" in 










database 














Other IBM 






Produce Daily 




(Audience) 






Report - 




Executives and their 






contingency, to be 




staffs 






defined 






Process Owner 


Information Sources 


Maintain Report 


Report Formats (as 


Authors 




Reporting 


Formats & Input 


Notes Stationery 


Captains 




Requirements of 


Criteria 


Items) 


Information Officers 




Report Recipients 




- Author Input 






Management Team 




- Captain's Brief 






& Marketing views 




-DPR 






of Information 




Input Criteria 


(i 




Sensitivity 




- Author Input 


si 








- Captain's Brief 










-DPR 




Process Owner 


Participent & 


DPR Communication 


Communication 


IBM (Audience) 
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End-user 


& Training 


Materials and Events 


Executives and their 






Communication & 




aimed at IBM 


staffs 






Training Needs 




Management 












Training Materials 












and Training 


Process Participants 










Delivered to 












participants as per 












agreed training needs 












(the end product of 












this activity is trained 












process participants 












and execs who 












understand how to 












access reports) 






Process Owner 


Notes Administrator 


Notes Administration 


Operational Notes 


Process Participants 






Requirements for 


& Support 


Databases, with 








Database, Mail 




Access Control Lists, 


IBM (Audience) 






Groups, user access 




Input Forms etc 


Executives and their 






etc 






staffs 






Help Desk Number 




Report Distribution 




Q 




and Escalation 




& Mailing Lists 








Charts 
















End User Support 






Process Owner 


Infrastructure 


Infrastructure 


DPR Infrastructure 


Operations 






Requirements 


Capacity 


Implementation Plan 


Sub-Project 




VITM 


Statement 


Management, 


Operation DPR 








Changes to Venue 


Operations & 


Notes 








Bill of Materials or 


Support 


Infrastructure & 








Layout 




Environment 












Updated Venue Bill 












of Materials 





Table 8 



5 As a further step, an analysis of critical customer requirements can be performed, 

with reference to Inputs, Process and Outputs, such that a description of the requirement can 
be made, a target/measure ascribed, and an impact assessed in that is not met. 

Furthermore, all inter-process dependencies can be defined in terms of the related 
10 process's identity, a description of the dependency, a timing or trigger, and a frequency or 
volume. 



Finally, milestones are allocated in terms of a "date required". For the present 
example, these includes: 

15 
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Item 


Responsibility for Action 


Date Required 


Infrastructure Requirements 
Specification & Implementation Plan 


(person) 


(date) 


Identify and finalise changes to Venue 
Equipment & Facilities 


(person) 


(date) 


Agree/finalise source data input criteria 
and report formats 


(person) 


(date) 


Prepare Metric spreadsheets and graphic 
output formats 


(person) 


(date) 


Finalise reporting deadlines and 
distribution lists 


(person) 


(date) 


Notes Administration & Support 
capability in place 


(person) 


(date) 


Databases and Email Ids created 


(person) 


(date) 


Performance testing complete 


(person) 


(date) 


Process Test & Training complete 


(person) 


(date) 


b tailing Flan tor Cluster lest bvent 


(person) 


^oate ) 


Final training for Cluster Test Event 


(person) 


(date) 


Cluster Test Event — DPR in production 


(person) 


(date) 


Debrief, lessons learned and process 
improvement plan 


(person) 


(date) 



Table 9 



5 D. Manual 

This methodology refers only to the need for there to be a protocol or document 
setting out process inputs, outputs, any exit criteria, and dependencies. 

Referring again to Fig. 8, the processes being ascribed the relevant criticality 
10 categories (ie. A, B, and C) have been indicated. Typically, category D is applied to certain 
management processes. 

Event Planning Milestones & Dependencies 
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Once the program framework has been established, it is traversed to execute the 
program. An essential function of program management is Schedule Control. When all 
outputs have been defined, process owners are required to translate process outputs into a 
time schedule. In this way time dependencies of the completion of each process can be 
5 identified. The use of task activity charts, and the like, is well known, however, the present 
invention takes the approach of identifying a subset of all task activities (specifically those 
that equate to the output of each process) and allocating milestones to process outputs that 
cut-across defined process streams. For Schedule control within a project, an activity in the 
project Schedule is only completed when it satisfies the pre-defined exit criteria. For 
10 Schedule control across projects, milestones are used. Milestones are groups of outputs 
produced by a Project Team, that are inputs to processers owned by other Project Teams. 
Milestones then represent the key dependencies between Project Teams, and are the primary 
Schedule control tool at a program level. 

15 Consider again Fig. 8, which identifies the following process streams: 

Workforce/training 
Process 

Testing/SW Control & Distribution 

Venues/Infrastructure/Device Configuration & Logistics/Operations 
Application Development 

Process streams are a string of processes typically assigned to a single Project Team. 
Where there is a link spanning one or more process streams, a milestone is defined to 
25 represent a dependency between Project Teams. Fig. 8 shows such milestones, indicated as 
Mn. 

The activities and milestones can be entered into a suitable scheduling tool, such as 
the Primavera Project Planner where there are assigned start and end dates and owners. On 
30 complex programs, the scheduling tool needs to be able to produce multiple views of 



(0 

(ii) 

(iii) 

20 (iv) 
(v) 
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activities and milestones. For Project Managers it needs to conveniently list the outputs (e.g. 
deliverables or services) and the resources required to produce them. For Program Managers 
the tool needs to list the milestones each project team is responsible for, together with the 
associated deliverables. 

5 

There is considerable advantage to forming a connection between significant process 
outputs and milestones in time. Firstly, attaching deliverables to milestones removes any 
ambuigity regarding whether a milestone has been achieved. Second, it identifies major 
cross-team dependencies, which will have a major cross-team impact in the event of schedule 
10 slippage. Additionally, being at a higher level than tasks/activities, it is easier for Program 
Managers to conduct a meaningful review of progress without having to become involved in 
the inner workings of individual project teams. 

Although the invention has been described with reference to a large-scale sporting 
15 event (via, the Olympic Games), it is to be appreciated that it is equally applicable to any 
other field of endeavour. This can include the burgeoning field of e-business as much as 
more traditional manufacturing and construction enterprises. 

The foregoing describes only a few embodiments of the invention, and modifications 
20 and/or changes can be made thereto without departing from the scope and spirit of the 
invention, the embodiments being illustrative and not restrictive. 
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